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Center, Hampton, VA. The NASA Technical Monitor is David J. Wing. 



Abstract 


Aircrews submit trajectory change requests to air traffic control (ATC) to better achieve the operator's preferred 
business trajectory. Requests are currently made with limited information and are often denied because the change is 
not compatible with traffic. Also, request opportunities can be overlooked due to lack of automation that advises 
aircrews of trajectory changes that improve flight time, fuel burn, and other objectives. The Traffic Aware Strategic 
Aircrew Requests (TASAR) concept leverages Automatic Dependent Surveillance-Broadcast (ADS-B) surveillance 
information to advise the aircrew of beneficial trajectory changes that are probed for traffic compatibility prior to 
issuing the request to ATC. This document describes the features, benefits, and limitations of TASAR automation 
hosted on an Electronic Flight Bag. TASAR has two modes: (1) auto mode that continuously assesses opportunities 
for improving the performance of the flight and (2) manual mode that probes trajectory changes entered by aircrews 
for conflicts and performance objectives. The roles and procedures of the aircrew and ATC remain unchanged under 
TASAR. 
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1. Introduction 


The NASA Traffic Aware Strategic Aircrew Requests (TASAR) Concept of Operations (ConOps) offers 
onboard automation for the purpose of advising the pilot of traffic compatible trajectory changes that would be 
beneficial to the flight. 1 The TASAR onboard automation is expected to be hosted on a Class II Electronic Flight 
Bag (EFB) and leverages Automatic Dependent Surveillance Broadcast (ADS-B) surveillance information to 
increase the likelihood of Air Traffic Control (ATC) approval of pilot-initiated trajectory change requests, thereby 
increasing the portion of the flight flown on or near a desired business trajectory. All automation and pilot 
procedures are fully dedicated to a single aircraft, which allows tailoring of optimization criteria to the specific 
objectives of each flight and provides for timely responses to changing situations. 

There is no change in separation responsibility under the TASAR concept. ATC has responsibility to separate 
Instillment Flight Rules (IFR) aircraft and maintains authority over the trajectories of all IFR aircraft in controlled 
airspace. IFR pilots are not permitted to make changes to their approved trajectory without first receiving approval 
from ATC. 


1.1. Scope 

This ConOps focuses on a range of capabilities for a near-term TASAR deployment within the current (2013) 
operating environment. The initial TASAR prototype deployment will, at a minimum, advise pilots of beneficial 
trajectory changes and leverage ADS-B surveillance information to increase the likelihood of ATC approval. Other 
capabilities described in this document, such as the potential future TASAR evolution paths in Section 5, 
may not be a part of the initial TASAR prototype deployment. This document also suggests how TASAR could 
evolve beyond a near-term deployment, but the near-term application remains the focus of this document. 

1.2. Background 

Referred to as user requests, trajectory change requests from aircrews may not be achieving their full potential 
to provide user benefits. Strategic traffic information is currently unavailable to most flight crews, so a trajectory 
change request has a reasonable chance of not being approvable by the controller because of resulting conflicts. The 
flight crew has access to tactical traffic information through the Traffic Alert and Collision Avoidance System 
(TCAS), but the time horizon of less than a minute to a few minutes is insufficient to check for conflicts. Also, 
probing for future conflicts to plan trajectory changes does not match the intended purpose of TCAS. Disapproved 
user requests are an operational detriment since they unproductively increase pilot and controller workload, 
contribute to radio frequency congestion, discourage further attempts by the pilot to optimize his flight, and do not 
produce a more desirable trajectory. In addition, conflict-free opportunities for improving the trajectory can remain 
undiscovered by pilots due to the lack of onboard traffic information and automation to compute more optimal 
trajectory changes that could be approved. 


1.3. Problem Statement 

Aircraft operating under IFR must fly trajectories approved by ATC. The approved trajectory often does not 
coincide with the aircraft operator’s preferred business trajectory. Less-desired trajectories can be the result of 
previously assigned non-optimal routes, altitude and/or speed restrictions issued by ATC, and changing conditions 
or priorities during the flight. Some causes of in-flight priority changes are unanticipated weather (e.g., convective 
weather, turbulence, and icing), destination change, the need to make up time as a result of an earlier delay or 
reroute to avoid traffic or weather, the need to delay the arrival due to traffic congestion at the destination, and the 
need to increase altitude as fuel is burned to improve efficiency. As a result, pilots have a need or desire to change 
their trajectory while in flight. Requests for such changes today are often denied because of projected traffic 
conflicts that might result from their use. 
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1.4. Document Overview 


This document is divided into the following sections: 

• Section 1 introduces the TASAR concept 

• Section 2 describes the roles and responsibilities of the controller, aircrew, and other actors within current 
operations 

• Section 3 describes shortfalls of current user requests that the TASAR concept addresses as well as a short 
description of procedural changes under TASAR 

• Section 4 provides a detailed description of the TASAR concept focusing on aircrew interaction with the 
onboard automation and the desired functions and behaviors of the onboard automation 

• Section 5 describes potential TASAR future evolution paths 

• Section 6 provides operational scenarios that show the interactions among the onboard automation, aircrew, 
controllers, and other actors 
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2. Current Operations 


This section describes the current roles and responsibilities of the aircrew and controller when aircrews send 
requests to controllers. The lists in Sections 2.1 and 2.2 are not comprehensive and are presented for the purpose of 
describing in Section 4 how TASAR aids the aircrew and controller in performing their roles and responsibilities. 
No change in aircrew or controller roles and responsibilities are suggested under the TASAR ConOps. 

2.1. Aircrew Roles and Responsibilities when Requesting a Trajectory Change 

Today, when requesting a trajectory change, the aircrew has the following roles and responsibilities. 

• Role of aircrew is to make trajectory change requests that meet their safety and efficiency objectives. 

• Aircrew has responsibility for safety of flight and will not request a trajectory change that compromises 
safety. For example, the aircrew considers fuel reserves, convective weather, turbulence, and icing. 

• Aircrew has responsibility to verify that the aircraft performance is sufficient to execute the change as 
requested. For example, the aircrew considers aircraft performance ceiling when making an altitude 
request. 

• Aircrew has responsibility to verify that the aircraft equipment is sufficient to execute the requested 
operation, e.g., Reduced Vertical Separation Minima (RVSM). 

• Aircrew has responsibility to generate requests that conform to operator policies and procedures. 

• Aircrew has responsibility to coordinate with dispatcher and company operations as necessary. 

• Aircrew has responsibility to limit requests so that the ATC voice communications frequency remains 
available for safety critical clearances. 

• Aircrew has responsibility to execute approved requests. 

• Aircrew has responsibility to execute or state inability to execute ATC amended requests. 


2.2. Controller Roles and Responsibilities when Responding to an Aircrew Request 

Today, when responding to an aircrew request, a controller has the following roles and responsibilities. 

• Controller will consider and approve aircrew requests when practicable. 

• Controller has responsibility to separate aircraft and will not approve a trajectory change request that 
violates minimum separation requirements. 

• Controller has responsibility to reject aircrew requests that violate their standard operating procedures or do 
not conform to traffic management initiatives that are in place. Flowever, certain restrictions and initiatives 
can be lifted after appropriate inter-sector coordination. 

• Controller has responsibility to issue clearances and respond to aircrew requests in such a way that the 
voice communications frequency remains clear for safety critical clearances. 

• Controller has responsibility to issue an approval, amendment, deferral, or denial in response to a request. 
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3. Justification and Description of Changes 


There are no changes to the roles and responsibilities of the aircrew or controller under the TASAR concept. 
The pilot uses current procedures to request the trajectory change, including determining the appropriate time to 
make the request. The pilot is not obligated to make any request including requests provided by TASAR 
automation. All information from TASAR automation is advisory only. No reference to TASAR is required when a 
request to ATC is made since no special consideration is being requested. 


3.1. Capabilities 

The TASAR concept provides additional onboard automation to aircrews with the following two functions that 
support aircrew requests: 

1. Calculating changes from the current trajectory to better meet user objectives such as fuel burn, flight time, 
and ride quality. 

2. Using ADS-B surveillance information to make trajectory change requests more acceptable to the 
controller by excluding those requests with conflicts at a short look-ahead time horizon that would be 
detected using the ADS-B information. 

These two functions address the capability shortfalls listed in Table 3-1. 


Table 3-1 List of Capability Shortfalls 


Capability 

Category 

Existing Capability 

Future TASAR Capability 

Capability Gap 

Aircrew preferred 
trajectory selection 

Post-departure trajectory changes 
depend on either ( 1 ) coordination 
with the flight dispatcher to take 
account of changing conditions or 
(2) experience, rules-of-thumb, or 
limited automation (e.g. 
computation of economy cruise 
speed) to make decisions 
independent of the flight 
dispatcher. 

Onboard automation can re- 
compute optimal trajectory in 
response to changing traffic and 
weather conditions as well as be 
responsive to the aircraft state 
and changing priorities of the 
operator and aircrew. 

Lack of automation for 
trajectory optimization on 
the flight deck. 

Aircrew manually enters winds 
into Flight Management System 
(FMS) at waypoints along 
trajectory. 

TASAR onboard automation 
integrates dynamic winds, 
convective weather, and 
temperature information when 
developing trajectory changes 
that improve objectives. This 
functionality does not include 
sending wind information to the 
FMS. 

Dynamic weather (winds, 
convective weather, 
temperature, turbulence) 
information is not 
integrated into onboard 
automation that computes 
trajectories. 

Aircrew estimation 
of trajectory change 
acceptability to the 
controller 

Aircrews use situational 
awareness obtained from voice 
frequencies as well as experience 
to estimate acceptability of a 
trajectory change to the 
controller. 

Onboard trajectory planning 
automation considers ADS-B 
surveillance infonnation in 
recommended trajectory changes. 

Lack of automation that 
considers surrounding 
traffic information on the 
flight deck in the selection 
of trajectory change 
requests. 

Aircrew estimates whether 
trajectory change will occur in 
current sector or a downstream 
sector based on experience and 
rules-of-thumb. 

Onboard automation uses 
knowledge of sector boundaries 
to determine if a trajectory 
change begins in the current 
sector or a downstream sector. 

Lack of automation that 
integrates sector boundary 
information into aircrew 
trajectory change request 
decision-making. 
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3.2. TASAR Automation Hosting 


The onboard automation is proposed to be hosted on a Class 2 EFB to permit read-only access to data from the 
aircraft’s systems, such as the FMS and flight control interfaces. A Class 2 EFB is physically mounted in the 
cockpit convenient to the pilot and therefore more likely to be used and provide benefit. 


3.3. Intended Users 

TASAR is intended to be used by any FMS-equipped civil flight operation in the continental United States that 
files IFR with a flight planned cruising altitude at or above 10,000 ft Mean Sea Level (MSL). Federal Aviation 
Regulations restrict aircrews to performing only those duties required for the safe operation of the aircraft below 
10,000 ft MSL excluding cruise below 10,000 ft MSL. This rule minimizes distractions to the flight crew during 
critical phases of flight that include taxi, takeoff, and landing. To be consistent across phases of flight, TASAR will 
become active when the aircraft is at or above 10,000 ft MSL and will deactivate after descending below 10,000 ft 
MSL. 

The 10,000 ft MSL floor could be set as a configurable parameter for users planning to cruise below 10,000 ft 
MSL. 
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4. TASAR Concept of Operations 


This section describes the aircrew interaction with the TASAR onboard automation and air traffic controllers. 
Section 6 expands on this section by presenting operational scenarios that describe the interactions. This section is 
organized as follows. 


Section 4.1 

Assumptions and Constraints 

Section 4.2 

Inputs from Aircrew 

Section 4.3 

Configurable Parameters 

Section 4.4 

Automated Information Gathering 

Section 4.5 

Dispatch Integration 

Section 4.6 

Probing for Trajectory Changes 

Section 4.7 

Displaying Trajectory Change to Aircrew 

Section 4.8 

Aircrew Request Negotiation with Controller 

Section 4.9 

Benefits to be Realized 


4.1. Assumptions and Constraints 

The Federal Aviation Administration (FAA) has mandated that aircraft be equipped with ADS-B OUT by 2020 
to operate in airspace that currently requires a transponder. If a sufficient percentage of aircraft are not equipped 
prior to the 2020 mandate (or have not enabled their ADS-B OUT systems), then the TASAR automation will still 
be able to offer optimized trajectory changes but will not be as effective in removing the potential for future 
conflicts. It is assumed that enough aircraft will be equipped prior to 2020 to provide sufficient traffic information 
for conflict probing or that sufficient supplemental traffic information is available from Traffic Information Services 
Broadcast (TIS-B) or other data sources. 

The TASAR concept may also be constrained by the broadcast power of the ADS-B OUT antenna for aircraft 
sending ADS-B messages and the sensitivity of the ADS-B IN antenna for aircraft receiving ADS-B messages. The 
air-to-air broadcast and reception range could be as short as 20 nautical miles (nmi) if aircraft equip to the basic 
requirements of the 2020 ADS-B mandate. However, airlines and high-end general aviation operations that operate 
at higher altitudes are expected to equip their aircraft with extended ADS-B equipage to achieve a minimum of 60 
nmi air-to-air range. 


4.2. Primary Inputs from Aircrew 

This section describes primary inputs that the aircrew will have the option of modifying during flight. Section 
4.3 contains additional parameters that will not typically be modified by the aircrew during flight. The aircrew will 
be provided with default settings for all of the inputs included in this section. 

(a) Mode of Operation 

TASAR automation operates in two modes: (1) automated monitoring for opportunities (Auto mode) and (2) 
pilot initiated use (Manual mode). In Auto mode, the TASAR automation performs a continuous assessment of 
opportunities for improving the performance of the flight. In Manual mode, the pilot enters a desired trajectory 
change into the automation interface which is then probed for conflicts and performance objectives. Conflict 
probing for both Auto and Manual modes is intended to be consistent with controller conflict probing described in 
Section 4.6. The TASAR automation indicates if there are conflicts known to the automation in Manual mode and 
computes a conflict-free modification to the desired trajectory change. 
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An Auto mode or Manual mode request may be denied by ATC, but ATC could offer a modification that is 
conflict-free and ask the aircrew if the modified trajectory meets the objectives of the aircrew. The TASAR 
automation and the conflict probe used by ATC may have differing knowledge of future four-dimensional (4D) 
trajectories of surrounding traffic that could cause the TASAR automation to consider the trajectory proposed by 
ATC to contain a conflict. In this case, a Manual mode without conflict probing may have utility by evaluating the 
trajectory against the objective function and aircrew constraints (e.g., time constraints, reserve fuel) but not probe 
for conflicts. 

The TASAR automation is in Auto mode by default and switches to Manual mode when requested by the 
aircrew or the automation senses the aircrew has entered a desired trajectory change into the FMS. 

(a) Aircrew Request Complexity 

The frequency of ATC issuance of clearances, the requests by other aircrews that are accepted or denied, the 
type of clearances issued by ATC, and the tone and urgency of the controller’s voice can all give an indication of the 
workload the controller is currently experiencing and the acceptable complexity of an aircrew request. More 
complex requests could be available in low controller workload situations but could be unavailable in higher 
workload situations such as routing aircraft around severe weather. The aircrew could dynamically increase or 
decrease the complexity of the request in order to tailor the request to the situation. 

Complexity would be defined by the number of entities in the request, with the lowest complexity requests 
being a simple “direct to” request or an altitude change. More complex requests would include adding one or more 
“off route” waypoints, as well as combining altitude and lateral (waypoint) requests. When generating a trajectory 
change, the TASAR automation will consider the pilot-selected request complexity as well as all levels below the 
selected request complexity. A default complexity setting will be provided. 

(b) Optimization Objective 

For operations in Auto mode, the aircrew selects the optimization objective, typically fuel burn, flight time, or a 
weighted combination of fuel burn and flight time. Passenger comfort and avoiding turbulence are also optimization 
considerations of the aircrew. Flowever, due to the general lack of turbulence predictability, Auto mode may not 
have the required information to search for trajectories that minimize turbulence. Instead, the aircrew could use 
Manual mode to evaluate a pilot-specified candidate route or altitude that may avoid turbulence based on ride 
reports. Convective weather regions made known to the TASAR automation could be avoided by an additional 
buffer specified in the configuration settings in Section 4.3 in an attempt to minimize the hazards of convective 
weather. 

Users may also desire to use TASAR automation to minimize overflight fees during international operations. 
Whereas initial TASAR deployment may be limited to operations in the continental United States, future TASAR 
deployments could include international operations with cost functions that minimize overflight fees. 

(c) Threshold for Aircrew Notification 

When operating in Auto mode, the automation will use a pilot-specified threshold for each objective (e.g., 
pound of fuel saved) for notifying the aircrew of an available trajectory change that sufficiently improves the 
objective. For weighted cost functions, each entity would have a settable threshold, rather than using a threshold for 
the entire weighted cost function. The aircrew may not have an intuitive feel for changes in the weighted cost 
function but will want to be notified if there has been a minimum improvement in either fuel or time. 

(d) Desired Trajectory 

Using Manual mode, the aircrew enters a desired trajectory change. This change could consist of a revised 
lateral path, an altitude change, or combination lateral/altitude change. For lateral path changes, the aircrew enters 
off-route named waypoints if desired and a reconnect point on the existing route, or the aircrew could enter just a 
downstream waypoint for a “direct to” request. 

Aircraft generally need to be on an arrival route at some point prior to the destination airport. This procedure is 
specific to each destination airport, and generally larger airports require aircraft to be on the arrival route farther 
upstream of the airport. By default, the Auto mode will reconnect at or prior to the first fix on the arrival procedure 
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on the originally filed route. If desired, or if the TASAR automation is unaware of the procedure, a pilot could 
specify a different waypoint to reconnect based on the pilot’s experience. This parameter is only applicable to Auto 
mode, since the pilot specifies the named waypoint where the reconnect occurs in Manual mode. 


4.3. Additional Input Parameters 

The parameters described in this section could be included if research or operational use indicate their utility. 
They may be additional aircrew inputs or could be specified in pre-flight configurations to help define the behavior 
of the TASAR automation. Configuration parameters would not normally be updated by the aircrew since they are 
more general than a single flight and are intended to generally represent the policies and procedures of the operator. 

(a) Time Constraint 

The aircrew may be subject to arrival time constraints at the destination airport, and the primary optimization 
objective may be to minimize deviation from or not exceed a scheduled arrival time. Examples include block time 
for the aircrew, airport curfew, gate availability, and passenger connections. The TASAR automation could apply a 
high penalty to the objective function if these time constraints are not achieved. 

Generally, the TASAR automation would not consider a time constraint by default. If the aircrew enters a time 
constraint, only solutions where the aircraft is projected to arrive at or before the time constraint would be presented 
to the aircrew, assuming the TASAR automation is able to find solutions that satisfy the time constraint. If the 
TASAR automation cannot find solutions that satisfy the time constraint, then trajectory changes would be presented 
that minimize deviation from the scheduled time. 

(b) Reserve Fuel Constraint 

The aircrew must ensure that certain constraints such as fuel reserves are not violated, since the violation of 
these constraints could impact flight safety. TASAR procedures will specify that the aircrew determines the 
acceptability of a request with respect to fuel reserves before making the request. The aircrew also coordinates with 
the dispatcher as required by standard operating procedures. TASAR automation is not intended to supplant existing 
systems and procedures for reserve fuel calculations or to display fuel reserve information. 

(c) Traffic Separation Buffer 

Whereas TASAR automation would apply standard separation criteria in its conflict probe of possibly trajectory 
changes, a configurable buffer could expand the conflict probe’s parameters for preventing conflicts. The buffer 
parameter would account for: (1) separation margin for increased controller acceptability, (2) different ownship 
trajectory predictions between airborne and ground systems, (3) surrounding aircraft trajectory uncertainties, (4) 
atmospheric and wind modeling differences between the air and ground, and (5) differences between ADS-B and 
ground-based surveillance. The buffer would be a configuration parameter not adjusted by the aircrew in flight. 

(d) Hazard Separation Distance 

The configuration could specify minimum desired separations to hazardous convective weather and special 
activity airspace (SAA). The aircrew could also define the threshold for convective weather based on, for example, 
NEXRAD reflectivity. 

(e) Optimization Update Rate for Auto Mode 

An optimization update rate parameter would specify how often the TASAR automation computes trajectory 
changes while in Auto mode. Reoptimizing accounts for: (1) trajectory changes of other aircraft, (2) changing 
winds, convective weather, temperature, and other atmospheric conditions, (3) SAA activation schedule changes if 
available, and (4) aircraft weight changes due to burned fuel. 



4.4. Automated Information Gathering 

The TASAR automation would gather traffic and hazard information using automated retrieval with no required 
aircrew action other than possibly powering up the system. 

(a) Airborne Surveillance through Various Sources 

TASAR automation will have knowledge of other aircraft through air-to-air ADS-B, ADS-B Rebroadcast 
(ADS-R), and TIS-B. Aircraft ADS-B equipment will use either the 1090 Megahertz (MHz) (1090 MHz Extended 
Squitter - 1090ES) or the 978 MHz (Universal Access Transceiver - UAT) radio frequency. The 1090ES will be 
used in all airspace, while UAT will be used below 18,000 ft MSL to correspond with the ADS-B rule requirements. 
Class A airspace above 18,000 ft MSL will contain 1090ES aircraft only, while all other classes of airspace will 
contain a mixture of 1090ES and UAT aircraft. Depending on the ADS-B receiving capability of TASAR aircraft, 
surveillance information from some aircraft may not be received if they are on the opposing frequency and other 
ADS-R or TIS-B broadcast requirements are not met. TASAR aircraft equipped with multi-mode receivers would 
directly receive ADS-B messages from all 1090ES and UAT aircraft within range. 

All ADS-B OUT equipped aircraft will broadcast state vector and mode status information, while aircraft 
equipped with ADS-B IN may also broadcast an air referenced velocity information. The state vector report 
includes the current latitude, longitude, geometric altitude, pressure altitude, north and east components of the 
horizontal velocity, and the vertical rate of the ADS-B target aircraft. The mode status report provides target aircraft 
characteristics such as broadcast capabilities and the quality of the broadcasted state vector data. The air referenced 
velocity report provides the airspeed and heading while airborne. Trajectory change reports that provide near-term 
4D aircraft intent may not be broadcasted, depending on current FAA regulations . 

(b) Surveillance through Airborne Internet 

Aircraft equipped with airborne internet access could use surveillance data available over an airborne internet 
connection to overcome limitations caused by incomplete ADS-B equipage, ADS-B equipment range, and lack of 
planned future 4D trajectories in ADS-B reports. The Aircraft Situation Display to Industry (ASDI) is one source of 
surveillance data that the FAA provides to subscribers to increase situational awareness. ASDI combines radar, 
ADS-B, and flight plan information from across the National Airspace System (NAS) into a single source of 
surveillance data. The ASDI messages most relevant to TASAR automation are the radar track update (TZ), flight 
plan (FZ), and flight plan amendment (AF) messages. The TZ message contains the flight identifier, latitude, 
longitude, altitude, and groundspeed. The FZ message contains the flight identifier, aircraft type, airspeed (true or 
Mach), proposed departure time, requested altitude, route of flight, and estimated time of arrival. Flight plan 
amendments contain altitude and route updates. 

Use of ASDI information by airborne systems has a number of limitations, including latency and quantity of 
data. Radar track data is updated at one minute intervals and could be delayed by five minutes or more before being 
downloaded from the internet, due to security requirements and other latency issues. Also, ASDI data is not filtered, 
so the aircraft could be sent a large volume of information with many flights that have no impact on the current 
trajectory of the aircraft. This issue could be mitigated by developing a separate system on the ground that filters 
data before sending to the aircraft. Airborne internet may have bandwidth limits to consider when the aircraft is 
downloading data. Also, ASDI messages are sent out continuously and flight plan and amendment information is 
only sent out once unless there is a change. Automation will not have access to these flight plans and amendments 
unless the automation is powered on and receiving data over the internet when the flight plans and amendments are 
sent. 

(c) Hazard Information 

Convective weather information would be available to the TASAR automation through onboard weather radar, 
airborne internet (if equipped), satellite weather, and Flight Information System Broadcast (FIS-B) (UAT or multi- 
mode ADS-B IN equipped aircraft only). Onboard weather radar is capable of detecting significant convection and 
lightning strikes at 200 nmi or more from the aircraft to provide an indication of the current weather in the forward 
direction of the aircraft. Satellite weather and FIS-B provide both provide NEXRAD reflectivity, which provides an 


9 



indication of current weather conditions, and convective Significant Meteorological Information (SIGMETs), which 
provide forecasted convection. 

Special activity airspace status is available through FIS-B and over the internet to aircraft equipped with 
airborne internet access. The TASAR automation will rely on published databases for terrain hazards since these 
hazards are not dynamic. Turbulence will not likely be considered by the TASAR automation initially. However, as 
the availability and quality of turbulence data improves, Auto mode functionality could be augmented to avoid 
current and forecasted turbulence. 

(d) Wind Velocity and Temperature 

The TASAR automation would gather wind velocity and temperature information and real-time updates from 
satellite weather, airborne internet (if equipped), or FIS-B to be used for trajectory optimization purposes. Updated 
wind field information in particular is key to effective trajectory optimization. 

(e) ATC Procedures and Sector Boundaries 

The TASAR automation may include a database of sector structure and letters of agreement between ATC 
facilities. However since they are not dynamic, updates will not be required during flight. 

(f) Traffic Flow Management Initiatives 

The FAA provides on-line tools to share reroute initiatives and active metering locations with airspace users. 
The websites do not provide flight-specific information, but it may be possible to determine if a flight will be 
impacted by the initiative. Aircraft equipped with onboard internet could have access to this information. 

The TASAR onboard automation may also dynamically compute sector congestion to determine where traffic 
flow management initiatives may exist. The monitor alert parameter indicates to traffic managers when a sector 
may be approaching capacity and an initiative may be required. The monitor alert parameter may be dynamically 
modified based on weather conditions and complexity of traffic flows in the sector. If these modifications are not 
available outside of FAA facilities, the nominal monitor alert parameter value could be used by the TASAR 
automation to estimate sector congestion. Sector traffic counts (which may be incomplete before the ADS-B 2020 
mandate) in nearby sectors could be dynamically constructed from airborne surveillance through ADS-B and TIS-B. 


4.5. Dispatch Integration 

TASAR automation may be integrated with Airline Operations Center (AOC) dispatch automation to help the 
aircrew make better requests and to keep dispatchers informed of aircrew actions. This section describes potential 
information sharing between the TASAR automation and dispatch which could be done over airborne broadband 
internet or another protocol. 

(a) Updated ATC Information 

Dispatch could have updated ATC traffic flow management (TFM) information that could influence which 
aircrew requests would be granted by ATC. For example, dispatch could be aware of a reroute initiative that has 
recently ended, and providing that information to the TASAR automation could result in the aircrew making a 
request that improves their objectives. 

(b) Dispatch Directs Aircrew to make Trajectory Change Request 

Dispatch may leverage fleet optimization and surveillance information functions on the ground to identify 
aircraft that could improve their trajectories or otherwise improve fleet operations. Once these aircraft are 
identified, dispatch could send messages to the aircrew or directly to TASAR automation indicating either a change 
in optimization objective or a specific trajectory change request to make to the controller. For the former, the 
aircrew updates the optimization objective in Auto mode, and the TASAR automation proceeds to seek trajectory 
changes for this new objective. For the latter, the aircrew would use Manual mode to probe the request for conflicts 
and other factors that influence acceptability of the request to the controller. In effect, the dispatcher is leveraging 
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the onboard TASAR automation to “time” the desired request to ATC such that approval is more likely, thereby 
increasing the effectiveness of the dispatcher’s flight optimization capabilities. 


(c) Aircrew Request Coordination with Dispatch 

Dispatch may wish to be informed of potential aircrew requests to (1) verify that a gate at the destination airport 
will be available if the aircraft arrives early, (2) check the impact on the fleet such as sequencing of flights at the 
arrival fix, or (3) verify that the requests improve the objectives of the operator based on the most up-to-date 
information onboard the aircraft (e.g., actual aircraft weight). Coordination with dispatch could be via automated 
downlink of the requested trajectory so that aircrews and dispatchers do not experience additional workload. 


4.6. Probing for Trajectory Changes 

This section describes the desired functions and behavior of TASAR automation when generating a more 
efficient trajectory. 

(a) Degrees of Freedom for the Trajectory Change 

The TASAR automation will search through the degrees of freedom listed in Table 4-1. The left column lists 
the objectives and constraints to be met by the trajectory change in the middle column. Examples of the trajectory 
change given in the right column of Table 4-1. Lateral and altitude trajectory changes need to be requested, while 
speed changes do not need to be requested (only reported if the speed change exceeds five percent of current 
airspeed or 10 knots, whichever is greater). However, if a controller issues a speed clearance, the aircrew must 
request deviations from the clearance. 


Table 4-2 Trajectory Changes 


Aircrew Objective(s) 
& Constraint(s) 

Trajectory Change 

Examples 

Objectives : 
Minimum fuel and 
minimum time 

Lateral route change to shorter wind optimal route. Will 
minimize fuel and time simultaneously. 

Direct to downstream waypoint. 
Switch to alternative route. 
Sequence of waypoints. 

Request another arrival fix. 

Constraint : 

Avoid hazards 

Lateral route change that avoids convective weather and 
SAA by buffer specified by aircrew inputs. This is 
intended to be a more strategic change when conditions 
allow a route change as opposed to a heading change. 

10 nmi parallel offset left of 
current track. 

Same examples as lateral route 
changes above. 

Objectives: 
Minimum fuel OR 
minimum fuel and 
minimum time 

Change altitude to reduce fuel burn but increase flight 
time (decrease groundspeed) OR change to altitude with 
sufficient tailwinds to reduce both fuel bum and flight 
time (increase groundspeed). Aircraft may have been at 
a less desired altitude due to optimal winds that have 
now shifted, altitude restrictions that have been lifted, or 
fuel weight that has been burned off during the flight. 

Request FL330 when flying 
FL290. 

Constraint : 
Avoid hazards 

Climb to higher altitude to avoid convective weather or 
terrain. Icing hazards can also be avoided by selecting 
another altitude. 

Request FL330 when flying 
FL290. 

Objective: 
Minimum fuel 

Increase or decrease airspeed closer to maximum-range 
cruise that minimizes fuel burn. 

Request Mach 0.78 when flying 
Mach 0.80. 

Objective: 
Minimum time 

Increase airspeed above maximum-range cruise to make 
up time. 

Request Mach 0.82 when flying 
Mach 0.78. 

Constraint: 

Avoid hazards 

Decrease airspeed to mitigate effect of turbulence. 

Request decrease in speed from 
Mach 0.82 to Mach 0.80. 


Shifting winds, fuel burned off during flight, changing aircrew priorities during flight, and previous assignment 
to a suboptimal trajectory will cause an aircrew to desire a lateral, altitude, speed, or combination of these as a 
trajectory change to be requested. Trajectory changes using lateral, altitude, speed, or a combination may also be 
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used to avoid hazards and surrounding traffic. However, the primary consideration is to generate trajectories to meet 
the combined objectives of the aircrew. 

(b) Conflict Probe 

The TASAR automation considers the following information when probing candidate trajectories for conflicts 
with other aircraft or hazards. Both Auto and Manual modes would use the same conflict probe functionality. 

• Ownship trajectory: Creates a four-dimensional trajectory from the TASAR-capable aircraft’s state and 
intent. Flight mode segments are generated using the aircraft’s flight plan, guidance modes, auto flight 
settings, and a performance model of the aircraft. 

• Surrounding traffic trajectories: Creates a four-dimensional trajectory prediction for each known traffic 
aircraft. If the flight plan is not known for an aircraft, or the aircraft is not following their flight plan, the 
prediction is based on the aircraft following their current heading, speed, and vertical rate. If the flight plan 
is known for an aircraft, the prediction is based on following the sequence of waypoints using current speed 
or the best information available. 

• Hazards: Static or dynamic regions of airspace that the aircraft must avoid or that the pilot prefers to avoid 
will be accounted for by the trajectory optimization function. 

• Buffers around other aircraft and hazards: A conflict is indicated if the ownship (or its buffered location) is 
predicted to come within a specified lateral/vertical volume of any traffic aircraft (or its buffered location) 
or breach the boundary of any hazard area. 

• The conflict probe would be configured to be consistent with current controller conflict probing look-ahead 
times. Generally, the onboard automation would probe approximately to a 10-minute look-ahead horizon. 
This shorter term probing is intended to improve acceptability to the current sector controller. Longer look- 
ahead horizons may reduce conflicts in the next sector but may also be succeptable to higher uncertainty 
from the longer-term trajectory predictions. If a conflict would be created in the next sector, the optimized 
trajectory change may be modified in order to prevent the conflict. The TASAR onboard automation may 
consider the tradeoff between the probability of a conflict and the impact on the preferred trajectory of the 
aircraft if the conflict occurs. 

(c) ATC Procedures 

Letters of agreement between adjacent ATC facilities impose constraints that restrict the trajectory (speed, 
altitude, heading, or route) of aircraft when transitioning across facility boundaries in order to manage traffic flows. 
These agreements are not readily accessable to the user community but could be leveraged by TASAR automation if 
made available by database or other means. If these constraints are available, the Auto mode search could favor 
trajectory changes that are consistent with ATC letters of agreement. Similarly, Manual mode could inform the 
aircrew of any potential issues with known ATC constraints. 

The following are possible TASAR considerations of ATC procedures involving facility letters of agreement: 

• Controllers have less freedom to grant requests that violate letters of agreement than other restrictions. 
Auto mode may be configured so that generated requests attempt to avoid violating letters of agreement in 
most cases. 

• Controllers are unlikely to grant requests during initial climb since these requests may conflict with arrival 
flows. However, when the aircraft reaches the high altitude structure, there is opportunity for granting 
requests, especially if the aircraft is far enough from the destination airport to not be impacted by metering 
restrictions. Auto mode could be configured so that requests are not generated below cruise altitudes. 

• Requests for wrong altitude for direction cause additional workload for the controller to coordinate with the 
adjacent sector. Auto mode could be configured so that requests that involve wrong altitude for direction 
are not generated. Alternatively, the aircrew could be warned that requests for wrong altitude for direction 
are less likely to be granted. 

• The distance upstream of the arrival fix where the aircraft merges into the arrival stream depends on the 
size of the airport. It is more acceptable to connect into the arrival route close to the arrival fix for small 
hub airports, while large hub airports generally require aircraft to be on the arrival route further out from 
the arrival airport. Auto mode requests could consider the first fix on the arrival procedure, as discussed in 
Section 4.2 (d), when generating lateral requests that reconnect to the arrival route. 
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• Controllers typically will not grant requests after initiating hand-off status with the next sector. The 
TASAR automation could consider sector boundary information and indicate to the aircrew when the 
aircraft is estimated to be within a threshold distance of the sector boundary and aircrew requests are less 
likely to be granted. 

• Not all controller routine behaviors are included in facility standard operating procedures. Over time, 
sector controllers develop methods to cope with traffic. The TASAR automation is not intended to infer 
controller behavior in this case. 

(d) Traffic Flow Management Initiatives 

TFM initiatives including metering and reroutes may be considered by TASAR automation. Metering may 
include miles-in-trail (distance-based) or required time of arrival (time -based) metering. TASAR automation may 
inform the aircrew that the aircraft may be part of metering when approaching congestion and that there could be a 
reduced likelihood of the request being granted. 

The TASAR onboard automation may also detect congested sectors as described in Section 4.4. Controllers 
will generally avoid sending traffic through an adjacent sector that is congested but may not be aware of congested 
sectors further away. If an aircrew request trajectory goes through an adjacent sector that it congested, it is likely to 
be rejected. However, if the aircrew request trajectory goes through another congested sector that is not adjacent to 
the current sector, then the request may be approved but the aircraft trajectory may be changed later to a less 
preferred trajectory to avoid the congested sector. Since the TASAR automation may not have the capability to 
accurately predict the trajectories of other aircraft to a longer time horizon, it is likely that TASAR automation 
would only consider congestion in the adjacent sector and possibly the sector beyond that during the Auto mode 
search. Manual mode may advise the aircrew if a trajectory change is projected to go through congested sectors. 
However, the ability to predict sector congestion depends on complete surveillance of the surrounding traffic. 
Predicting sector congestion may not be a useful function without means to receive data on all traffic regardless of 
ADS-B equipage. 

An aircraft may also be part of a reroute initiative to avoid weather or mitigate more strategic sector congestion. 
In this case, the pilot will be aware if it is acceptable to make a request. Auto mode functionality will continue to 
search for trajectory improvements when the aircraft is part of a reroute initiative in order to provide the flexibility 
to the pilot to send a request if desired. 

(e) Facilitating Voice Communications 

Voice communication places practical restrictions on the complexity of aircrew requests. Section 4.2 proposed 
that the aircrew dynamically select a maximum complexity (i.e., number of elements in the request) depending on 
the situation. The default complexity is expected to be limited to two off-route waypoints. Combination altitude 
and lateral requests must be made simultaneously and may be limited to one off-route waypoint in addition to the 
requested altitude. 

When generating waypoints, the TASAR automation restricts the trajectory to named waypoints to facilitate 
voice requests. These named waypoints will be considered along with other trajectory changes in the following 
order of preference from most preferred trajectory change to least preferred trajectory change: (1) named high 
altitude VORs (Very-high-frequency Omnidirectional Range) and fixes, (2) named low altitude VORs and fixes, (3) 
parallel offset from current track or airway, and (4) desired heading or range of headings. 

Due to technical limitations, the controller workstation may not have all waypoints in a database readily 
available to the controller. If the waypoint is not in the database, the controller may need to manually enter the 
details of the waypoint which is a time consuming process. The TASAR automation will only develop lateral route 
requests that contain waypoints in the database. The database is center-specific, and so the TASAR automation 
would update available waypoints upon crossing a center boundary. 


4.7. Displaying Trajectory Change to Aircrew 

If the TASAR automation incorporates sector boundary information, only trajectory changes that begin in the 
current sector will be displayed to the aircrew, since controllers are primarily concerned with trajectory changes that 
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occur in their sectors. Generally, trajectory change requests should not be made more than one or two minutes prior 
to the start of the trajectory change. Trajectory changes that occur downstream of the current sector would be 
presented to the aircrew when the aircraft enters the downstream sector where the proposed trajectory change will 
occur. The following subsections describe information that would be presented to the aircrew. 

(a) Standby until Minimum Altitude 

The TASAR automation displays a standby screen until the aircraft reaches an altitude at or above 10,000 ft 
MSL to correspond with the behavior described in Section 3.3. 

(b) List of Trajectory Changes that Improve Objectives (Auto Mode) 

A list of trajectory changes that improve the objectives of the aircrew and avoid hazards and traffic will be 
presented. Only those trajectory changes that are sufficiently free of conflicts and are determined to be otherwise 
acceptable to controllers will be presented to the aircrew. Once the aircrew makes the request to the controller, the 
aircrew has the option of freezing the requested trajectory change to prevent further updates. 

(c) Modifications for Conflict-Free Pilot-Specified Preferred Trajectory (Manual Mode) 

If the pilot enters a trajectory that does not avoid hazards or other traffic, then modifications to make the 
trajectory conflict free are presented at pilot request. 

(d) Outcomes of Trajectory Change (Auto and Manual Modes) 

The predicted change in fuel burn and flight time will be presented to the aircrew. The predicted distance to 
hazards and other traffic will not be presented to the aircrew since the trajectory changes presented will be at least 
the minimum required distance plus any buffers. 

(e) Conformance with Standard Procedures and Letters of Agreement (Manual Mode) 

If a trajectory change is not consistent with ATC standard procedures or violates a letter of agreement between 
facilities, the aircrew would be notified of the issue with the trajectory change entered by the aircrew. TASAR may 
also indicate if a request has a reduced likelihood of approval due to, for example, the aircraft being in handoff 
status to the next sector controller or the aircraft being too close to the destination aiiport. 

(f) Traffic Management Initiatives (Manual Mode) 

It may be desirable to inform the aircrew that the aircraft is part of a metering situation or reroute initiative, or 
that the trajectory change is projected to enter congested sectors. 

(g) Time to Trajectory Change (Auto and Manual Modes) 

The time to the location where the trajectory change should occur is presented to the aircrew. If not presented, 
the trajectory change is assumed to be immediate. 


4.8. Aircrew Request Negotiation with Controller 

The aircrew (not the TASAR automation) decides when a request is appropriate and makes a request to the 
controller. The response to controller approval, deferral, denial, or amendment is as follows. 

(a) FMS Verification 

Prior to issuing a TASAR request, the aircrew will use the FMS to verify that the TASAR request is flyable and 
will improve the objectives of the aircrew. Due to different aircraft performance models and atmospheric 
information between the TASAR automation and the FMS, it is possible that the TASAR automation may identify a 
trajectory change it estimates as beneficial while the FMS may indicate that executing the request would not be 
beneficial. If there is disagreement between the TASAR automation and the FMS, the FMS should be used as the 
authoritative source. Pilots may have the option to enter updated information into the FMS (e.g., winds) in order for 
the FMS to recognize that a TASAR generated request is beneficial. 
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(b) Confirm with Dispatch 

Company policies regarding pilot/dispatcher coordination of flight plan changes are not altered by TASAR. 
Where required, this coordination could be automated through TASAR as described in Section 4.5. 

(c) Approval 

If the request is approved by ATC, the aircrew will execute the trajectory change. The TASAR automation will 
detect that the trajectory change has been executed and start computing trajectory changes relative to the executed 
trajectory change. The TASAR interface may provide means for the pilot to record the request was approved, 
deferred, denied, or amended. 

(d) Deferral 

If the controller defers the request, the TASAR automation continues to compute the optimization objective 
function without developing modifications to produce a trajectory free of conflicts. If the trajectory change is no 
longer optimal, the aircrew will use their best judgment to determine whether to cancel the request. 

(e) Denial 

The TASAR automation will not be updated in response to a controller denial of a request since the controller is 
unlikely to communicate why the request was denied. Instead, the potential requests presented to the aircrew will 
continue to be updated as the flight progresses. 

(f) Amended Trajectory 

Generally, a pilot will know if the ATC amendment is still advantageous and will be able to accept or reject the 
amendment without automation assistance. However, entering an ammended trajectory change offered by ATC into 
the TASAR automation using Manual Mode will be an option for the pilot to verify if the amended trajectory change 
is desired. 


4.9. Benefits to be Realized 

A preliminary fast-time simulation study showed that, on average, aircraft equipped with TASAR can reduce 
travel time by about one to four minutes per operation and fuel burn by about 50 to 550 lbs per operation, 
depending on the objective of the aircrew, class of airspace user, and aircraft type. 2 Benefits are estimated to be 
higher at longer stage lengths since beneficial trajectory changes can be applied over a longer distance. The benefit 
mechanisms that elicit these benefits are discussed in this subsection. 

A benefit mechanism is a causal linkage that converts a function into a benefit by applying the function to 
mitigate inefficiencies. Probing desired trajectory changes for possible separation violations with nearby traffic is 
one function for the benefit mechanism shown in Figure 4-1. This function is expected to mitigate the issue that 
aircrew requests are not always conflict free and are therefore sometimes denied. The other function shown in 
Figure 4-1 is the capability for TASAR-equipped aircraft to generate user-preferred trajectories, which mitigates the 
issue that the aircraft may not be following their preferred trajectory due to a previous inefficient trajectory 
assignment, a change in flight priorities, or a change in the environment (e.g., winds or weather). 

The mechanisms shown between the first and second vertical dashed lines are enabled by these two functions 
and result in the four benefits shown between the second and third vertical lines in Figure 4- 1 . 

The five benefits shown are: (1) aircrew better able to meet their objectives (delay. Riel costs, passenger 
comfort, etc.), (2) improved National Airspace System (NAS) performance, (3) reduced nuisance requests, and (4) 
reduced conflicts for controller to resolve. In order to quantify these benefits, four metrics are shown in boxes with 
dashed lines in Figure 1. These metrics are, respective to the four benefits: (1) aircrew utility, (2) NAS-wide delays, 
fuel burn, and congestion, (3) aircrew requests rejected by the controller, and (4) conflicts resolved by controller. 
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Figure 4-1 TASAR Benefit Mechanisms 


Potential negative impacts of TASAR on the NAS are also considered, in addition to the benefits described in 
the previous subsection. Figure 4-2 shows potential impact mechanisms in a format similar to the benefit 
mechanisms shown in Figure 4-1. Four possible impacts are: (1) potential for increased controller workload if 
TASAR equipage grows too rapidly, (2) potential for increased user request denials if TASAR requests use 
insufficient margins of separation, (3) increase in conflicts to be resolved by the controller, and (4) potential for 
increase in airspace complexity. The expectation is that TASAR will reduce the conflicts for controllers to resolve, 
but there may be cases where TASAR resolves the immediate conflict but the resulting traffic situation may cause a 
controller downstream of the current sector to deal with more conflicts overall. 



Figure 4-2 Mechanisms for Potential Negative Effects of TASAR 
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TASAR may provide two important benefits in meeting the challenge of airspace system modernization. (1) Its 
near-term operational use will provide a better technical understanding of ADS-B surveillance and its use by 
onboard automation, leading to the development of advanced concepts that involve a high degree of aircraft and 
flight crew autonomy. The development of TASAR should also provide a better understanding of the data and 
computational needs of the aircrew when planning their trajectory to meet their objectives. (2) Perhaps more 
importantly, TASAR may provide a user incentive for equipping aircraft with ADS-B, thereby accelerating equipage 
in advance of the 2020 ADS-B Out equipage mandate. Given the 2020 mandate, it is assumed that aircraft will 
equip with ADS-B Out when equipping with ADS-B In to obtain the TASAR single aircraft benefits. 
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5. Potential Evolution Paths for TASAR 


TASAR will need to evolve to be consistent with future NAS operations and to take advantage of the Next 
Generation Air Transportation System (NextGen) operational improvements. Operational improvements that are 
presented in this section were obtained from the National Airspace System Enterprise Architecture (NAS EA) 
website ( https://nasea.faa.govf ). 


5.1. 4DT Negotiation via DataComm 

Initially, TASAR requests will be limited to named waypoints over voice communications. The introduction of 
data communications (DataComm) will allow for more complex TASAR requests, such as waypoints defined by 
latitude and longitude, to allow the aircraft to more closely follow the preferred trajectory of the operator. 

DataComm will eventually be used in NextGen to transition from routes defined by named waypoints to four- 
dimensional trajectories (4DTs) defined by three-dimensional spatial locations and time. TASAR algorithms would 
generate modifications to 4DTs including new fix time objectives in their definition to facilitate trajectory 
negotiation. 


5.2. Flight Deck Planning with ANSP Feedback 

One of the NextGen operational improvements is intended to allow flight crews to do trial planning from the 
flight deck. This trial planning will be enabled by aircraft access to system-wide information management (SWIM) 
and air navigation service provider (ANSP) ground automation tools that provide feedback on constraints impacting 
the trajectory. TASAR could be used as the automation function on the flight deck that generates optimized 
trajectories which are then sent over SWIM or direct downlink to be probed by ground automation. The TASAR 
automation algorithms would then need to revise the optimized trajectory based on feedback received from the 
ground automation tools. 


5.3. Enhanced Flight Plan with Alternative Trajectories and Preferences 

Under NextGen, it is expected that the flight plan will contain information regarding user preferences, such as 
ranked alternative trajectories. These preferences will be used by the ANSP to generate traffic management 
initiatives that better meet the preferences of the airspace users. One potential role for TASAR automation could be 
to continually evaluate these alternative trajectories to search for the most optimal alternative. If better alternatives 
are found, the flight deck planning with ANSP feedback function described in Section 5.2 could be used to evaluate 
the alternatives. 


5.4. Types of Trajectory Constraints 

Time-based metering, point-in-space metering, and 4DTs are all part of a NextGen shift by the ANSP to 
generate traffic management initiatives with flight-specific trajectories. TASAR automation will need to account for 
these types of constraints when generating more optimal trajectories, as well as other NextGen initiatives such as 
delegated separation and performance-based access to airspace and routes. 
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6. Operational Scenarios 


This section describes sample scenarios corresponding to the two TASAR modes: Auto mode and Manual 
mode. Each of these scenarios define a range of aircrew objectives, the preconditions that cause the aircraft to be on 
a less desired trajectory, the post conditions after the request is granted, and the steps in the scenario. 


6.1. Sequence for Automated Monitoring for Opportunities (Auto Mode) 

Aircrew objectives: 

1) Minimize flight time, OR 

2) Minimize fuel burn, OR 

3) Minimize weighted combination of flight time and fuel burn 

Precondition alternatives that cause the aircraft to be on a less desired trajectory >: 

i. Planned route is not wind optimal post-departure, or winds shift during flight, or aircraft changes 
lateral route to cause another altitude to be wind optimal. 

ii. Aircraft is part of a reroute initiative to avoid convective weather or mitigate congestion, and aircraft 
are not shifted back to user-preferred routes after the initiative has ended. Or aircraft is part of an 
altitude capping or tunneling initiative and aircraft is not returned to user preferred altitude after 
initiative has ended. 

iii. Convective weather impacts aircraft en route. This is intended to be a more strategic change when 
conditions allow a route change as opposed to a series of ad hoc heading changes. Or convective 
weather is projected to impact current trajectory and aircraft is capable of climbing over convective 
weather by required buffer. 

iv. Convective weather shifts allowing a more preferred tactical trajectory change. 

v. Change in activation schedule of SAA while aircraft is airborne. 

vi. Aircraft is at a lower altitude than desired to minimize fuel burn. Aircraft burns off weight during 
flight to allow climbing to a higher, more fuel efficient altitude. 

vii. Aircraft is destined for a smaller airport (e.g., TEB) but is caught in an arrival stream of a larger airport 
(e.g., JFK) causing the aircraft to be flying slower than desired. Higher altitude is desired to bypass 
larger airport arrival stream. 

Post conditions after request approved: 

1) Aircraft following approved, more optimized trajectory 

2) Utility of operator increased 

Main Scenario: 

1 . Flight crew receives initial flight plan from dispatcher. 

2. Flight crew receives initial business objectives for the TASAR automation from dispatcher if dispatcher 
provides business objectives. Otherwise, the flight crew will select a default configuration for the TASAR 
automation in step 7. 

3. Flight crew enters flight plan into FMS. 

4. Aircraft departs and is flying IFR cruise in en route airspace. 

5. Onboard TASAR automation becomes active once the aircraft is above 10,000 ft MSL. 

6. TASAR automation receives current flight plan from FMS. 

7. Flight crew enters initial objectives into TASAR automation or uses a default TASAR automation 
configuration. 

8. TASAR automation is in Auto mode by default. 

9. TASAR automation receives updates (if any exist) from flight operational control or internet source (if 
equipped). 

10. Flight crew receives updated objectives from dispatcher (if objectives have changed). 
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11. Flight crew enters updated objectives into TASAR automation (if objectives have changed). 

12. TASAR automation receives updated position/state of aircraft equipped with ADS-B Out as well as 
aircraft not equipped with ADS-B Out from TIS-B. 

13. TASAR automation receives updated weather, winds, and atmospheric information from satellite weather, 
FIS-B, or internet depending on aircraft equipage. 

14. TASAR automation receives updated SAA activation schedule from FIS-B or internet depending on 
aircraft equipage. 

15. Preconditions i to vi 

16. TASAR automation identifies aircraft is not following preferred business trajectory to meet flight 
objectives. 

17. TASAR automation creates a 4D trajectory prediction for the ownship as well as all aircraft known 
through ADS-B. 

18. TASAR automation identifies conflict-free (to a time horizon) lateral, altitude, or combination lateral and 
altitude trajectory change that improves objective. 

19. TASAR automation indicates to flight crew that threshold for making request is exceeded. 

20. TASAR automation indicates attributes of the trajectory change to the flight crew. 

21. TASAR automation indicates to the flight crew the estimated time to when the trajectory change will 
occur. 

22. Flight crew selects trajectory change which freezes the TASAR automation from further updates. 

23. Flight crew verifies with FMS that request will improve objectives. 

24. Flight crew verifies that request will not result in a violation of required fuel reserves. 

25. Flight crew makes request to controller. 

26. Controller approves request if acceptable. 

27. If controller approves the request, the flight crew executes the approved request in the FMS and TASAR 
automation receives the updated trajectory from the FMS. 

28. TASAR automation continues searching for trajectories in Auto mode. 

Precondition i (Shifting winds): 

TASAR automation identifies that winds have shifted and preferred lateral trajectory or preferred altitude may 
have changed. 

Precondition ii (Restriction no longer needed): 

Dispatch notifies flight crew or flight crew determines from voice communications with ANSP that route or 
altitude restrictions are no longer needed. 

Precondition iii (Shifting convective weather): 

TASAR automation monitors for growth, decay, or shifting of convective weather to alter a strategic route or 
recommend an altitude change. 

Precondition iv (Shifting convective weather): 

TASAR automation monitors for growth, decay, or shifting of convective weather to allow a tactical heading 
change. 

Precondition v (Activation/schedule change for SAA): 

TASAR automation identifies available SAA airspace that was previously unavailable due to a change in SAA 
activation schedule 

Precondition vi (Change in aircraft ceiling): 

Aircraft burns off sufficient fuel to allow aircraft to climb to a more advantageous altitude. 

Precondition vii (Aircraft caught in slower arrival stream): 

Airspace above aircraft clear enough to allow climb to another altitude and airspeed increase. 
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6.2. Sequence for Pilot Initiated Use with Conflict Probing (Manual Mode) 

Aircrew objectives: 

1) Minimize flight time, OR 

2) Minimize fuel bum, OR 

3) Minimize weighted combination of flight time and fuel bum, OR 

4) Minimize turbulence or weather avoidance 

Preconditions that cause the aircraft to be on a less desired trajectory >: 

i to vii. Same as Auto mode. 

viii. Icing impacts aircraft during flight. 

ix. Aircraft is diverted to alternate airport. 

x. Aircraft is delayed en route and needs to make up time. 

xi. Aircraft is impacted by turbulence. 

xii. Conditions at destination airport require diverting to an alternate airport or, for business operators, 
onboard passengers request a change in destination. 

Postconditions after request approved: 

1) Aircraft following approved, more optimized trajectory 

2) Utility of operator increased 

3) Better ride for passengers 

Main Scenario: 

1. Steps 1 to 14 from Auto mode steps in Section 6.1. 

2. Preconditions i to xii 

3. Aircrew enters desired lateral, altitude, or speed trajectory change into FMS or onboard TASAR 
automation. 

4. If trajectory change is entered into FMS, TASAR senses the trajectory change. 

5. TASAR automation creates a 4D trajectory prediction for the ownship as well as all aircraft known 
through ADS-B. 

6. TASAR automation probes for conflicts. TASAR automation develops conflict-free (to a time horizon) 
modification if necessary. 

7. TASAR automation checks for violations of standard procedures or letters of agreement. TASAR 
automation notifies flight crew of any violations. 

8. TASAR automation indicates attributes of the trajectory change to the flight crew. 

9. TASAR automation indicates to the flight crew the estimated time to when the trajectory change will 
occur. 

10. Flight crew verifies with FMS that request will improve objectives. 

1 1 . Flight crew verifies that request will not result in a violation of required fuel reserves. 

12. Flight crew makes request to controller. 

13. Controller approves request if acceptable. 

14. If controller approves the request, the flight crew executes the approved request in the FMS and TASAR 
automation receives the updated trajectory from the FMS. 

15. TASAR automation continues searching for trajectories in Auto mode. 

Precondition xii (Diverting to alternate airport): 

1. Aircrew selects option from TASAR automation to search for alternative destination airports. 

2. TASAR automation develops list of alternative airports that are reachable. 

3. Aircrew selects desired alternative airport. 

4. TASAR automation displays lateral trajectory to destination airport. 
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7. Definitions 


1090 MHz Extended Squitter (1090 ES): Extended Squitter Automatic Dependent Surveillance-Broadcast 
equipment operating on the 1090 Megahertz radio frequency. 

Automatic Dependent Surveillance-Broadcast (ADS-B): A surveillance service using the automatic transmission 
of an aircraft's or surface vehicle's position and other state information. The source of ADS-B information is 
derived from the aircraft's navigation system (e.g.. Global Navigation Satellite System receiver. Flight Management 
Computer, etc.). Other aircraft may receive this information and compare it to their own position to accurately 
determine relative position. Ground systems may also use ADS-B information to augment or replace less accurate 
radar-based surveillance information, or to provide cost effective surveillance coverage in non-radar airspace. 

ADS-B Report: An ADS-B Report contains the information elements assembled using messages received from a 
transmitting participant. These information elements are available for use by applications external to the ADS-B 
system. 

ADS-B Message: An ADS-B Message is a block of formatted data that conveys the information elements used in 
the development of ADS-B Reports. Message contents and formats are specific to the ADS-B data link. 

Airline Operations Center (AOC): Centralized organization staffed by certified flight dispatchers responsible for 
the planning and conducts of airline flight operations. 

Air Traffic Control (ATC): Service by ground-based controllers to separate traffic, organize traffic flow, and 
provide information and other support to the pilot when the controller is able. 

Electronic Flight Bag (EFB): Computing platform on the flight deck designed to reduce paper-based reference 
material and to automate calculations. 

Flight Management System (FMS): Automation to help flight crew guide aircraft along flight plan. 

Instrument Flight Rules (IFR): Flight crew operates aircraft solely by reference to instruments. 

Mean Sea Fevel (MSF): Mean height of the surface of the ocean. 

Reduced Vertical Separation Minima (RVSM): 1,000 ft minimum vertical separation between flight level 290 
and Flight Level 410. 

Traffic Aware Strategic Aircrew Requests (TASAR): Onboard automation leveraging ADS-B surveillance 
information for the purpose of advising the pilot of traffic compatible trajectory changes that would be beneficial to 
the flight. 

Traffic Alert and Collision Avoidance System (TCAS): Alerts pilots of increased collision risk and, under certain 
conditions, recommends maneuver to reduce risk of collision. 

Traffic Flow Management (TFM): Planning and execution of plans by ATC to maintain demand for airspace and 
airport resources below capacity through use of flow controls such as ground stops, ground delays, metering, and 
rerouting. 

Traffic Information Service Broadcast (TIS-B): Uplink of surveillance information (ground radar or aircraft 
targets on another ADS-B frequency) on ADS-B data link to supplement air-to-air ADS-B surveillance. 

Universal Access Transceiver (UAT): Universal Access Transceiver Automatic Dependent Surveillance - 
Broadcast equipment operating on the 978 Megahertz radio frequency. 
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